Applications evolve over time. Changes are made to support new features, and old features are dropped. Changes to a database application usually require changing database objects. For example, tables are changed by adding or dropping columns. Indexes are added to support faster or different queries. Views are modified to support changes in the table shape, and even whole tables may be added or dropped. “Schema evolution” refers to the changes that occur to an application's database objects over time.
Replication complicates schema evolution, because copies of the database objects are stored on multiple sites in a distributed network of database systems. Before any of the administrative operations in schema evolution are performed at one site for a particular database object, any activities requiring replication for that database object must be suspended, or “quiesced,” at all sites. Quiescence allows all previously made replication activities to complete, so that all replicated modifications may be performed consistently with respect to the administrative environment at each site. Thus, replication is quiesced at all sites to prevent inconsistent modifications to replicated data. One implementation of quiescence is described in the commonly assigned U.S. Pat. No. 5,991,768 entitled “Finer Grained Quiescence for Data Replication” issued Nov. 23, 1999 to Harry Sun et al., the contents of which are incorporated by reference as if fully set forth herein.
In large-scale distributed database systems with many master sites, quiescence of every master site at the same time is often awkward or impractical. For example, changing a replicated table requires quiescing all of the masters that are replicating the table, changing the table, regenerating replication support for the table, and resuming replication of the table. For configurations that support many master sites, or have masters in different time zones, this approach may not be practical.
Practical support for schema evolution is much more difficult when the distributed database system includes disconnected sites, such as laptop computers in front office automation. Recently, there has been much interest in the marketplace for applications for front office automation. One example is sales force automation, where hundreds, if not thousands, of sales representatives in a company are given laptops to improve their productivity. The laptops are loaded with applications and a data store, for example, to keep the customer and order information handy for use by a specific sales representative for selling the company's products to a customer and taking the customer's order.
Thus, in front office automation deployments, there may be hundreds or even thousands of client databases. These databases, however, are not connected for very long periods of time, and it is exceedingly rare that that all of them are connected at the same time. Consequently, quiescence for such deployments is an extremely difficult, if not impossible, administrative task to perform.